@adamw Adding proper handling for non-ws responses in ws endpoints made me think that it's better to remove ReactiveWebSocketHandler entirely. It would realize a majority of logic done by the standard NettyServerHandler plus handshake handling. Instead, I put handshake handling as an additional case in NettyServerHandler. Maybe it's worth extracting the body of initWsPipeline to a function in an object located in the ws package, but I'm not sure about that. WDYT?

@kciesielski yeah if that's feasible, sounds good, might clean up the code :) Not sure about extracting the code to a WS package, you would loose the possibility to call the 500/400 response-generators then? But maybe these should be simply put in yet another "common" object, NettyErrorResponses or such

Hmm such extractions require further refactoring, because response handlers are internal implicit classes referencing fields of NettyServerHandler (like request, isShuttingDown, etc.).

@kciesielski let's skip them then ;)

otherwise this PR will end up being gigantic feature + refactor

I'm totally on the same page on this 😁

I'm reading through the codebase to get a better mental model of this, but since I'm generally not familiar with it (nor with websockets in detail, for that matter), it might take me some time until I can submit some non-superficial review. Not sure if there's any point in waiting for me :)

Thank @ghik, your comments were helpful :)
@adamw waiting for your approval then.

I think in the end code is even simpler now. Great work - let's ship it :)